Since the inception of computer systems for business in the early 1950s (and even earlier, beginning with the advent of card sorting machines), there has been a constant expansion of the functionality of automated and computerized business systems and of the central role played by these systems in the business organization. Today, a large size organization, for example, one to be found in the “Fortune 500” list of public corporations, is likely to have many different computer systems and platforms, using a wide range of operating systems, and even a wider range of programming languages. The total number of computer application systems used in these organizations can number in the thousands, and the majority of these application systems will need to exchange information with each other, many of them in “real time”. Even the large applications in these environments, the so-called “mission critical” applications upon which the organization is dependent for on-going daily operation, can number in the hundreds, and may need to exchange huge amounts of data on a daily basis with each other and with many computer systems that may be external to the organization.
In the beginning, computer systems comprised single units of code, or programs, that provided all the aspects of the application system, including reporting, data transaction processing, user interface, workflow and business rules (program logic). As these programs were connected together to form systems the levels of complexity became compounded. Methods, tools, and evolving theory have been required to deal with this ever increasing complexity. Two of the strategies that have been used to combat this ever increasing complexity, and which are relevant to the present invention, are known as “separation of concerns” and “visualization”.
Separation of concerns is based on the assumption that, within any given system, different parts of the system would handle different aspects of the system, such as reporting, data management, transaction processing, user interface, business rules and business logic, etc. In this way it is possible for one aspect of the system to be changed without affecting the rest of the system.
The separation of concerns led over time to the development of systems that had multiple “tiers” (these are called “n-tier” systems) or layers, where each tier would be responsible for a different aspect of the system. A typical n-tier system would consist of a tier responsible for the user interface (and other “presentation” type interfaces), a tier responsible for system workflow, a tier responsible for application logic, business rules and business logic, and a tier responsible for data. The tiers would be connected one to another by various messaging systems using standardized message formats, and so each tier could be developed and changed independently from the other tiers.
Evolving from this theory of separation of concerns came the idea to split the business rules, or business logic, from the rest of the program code, program the business rules into separate, discrete packages of business rule code, and execute that code on “Business Rule Engines”. These engines were purpose built computer systems optimized to execute the business rules. In many architectures the business rules and their business logic were separated into their own tier in the n-tier architecture.
There are good reasons why business rules are excellent candidates for separation from other aspects of the program code and possibly placed into a separate tier of the architecture. Business rules tend to change more frequently than the rest of the program, because of changes in business condition and/or regulations. Also, changes in business rules are either totally at the discretion of the business (i.e., how the business wishes to handle certain business situations) or are required in order to be compliant with mandatory regulations. When business rules are integrated into the programs, finding and isolating specific rules within the code that are required to be changed to reflect a particular business or regulatory change is extremely difficult, as the program logic may be very complex. The code for a single rule may be scattered, spread across multiple different sections of or places in the code, and may be duplicated in many different programs across a system. It may also be found in many different systems.
By separating the business rules, and storing them discretely in business rule engine software products, business analysts working with programmers could be given relatively simple access to them to insure that they accurately reflected the will of the business users. Over time these purpose built products became known as Business Rule Management Systems (BRMS). Exemplary commercial BRMS vendors and their BRMS products include: Fair Isaac Corporation (Blaze Advisor), ILOG (ILOG JRules), Microsoft Corporation (BizTalk Server), and Pegasystems (SmartBPM Suite).
The BRMS proved a successful and relatively popular solution to the challenge, particularly for organizations where business rules abound, and where they need to be changed often. Increasingly, since the mid 1990s, application development for large scale application has included a certain amount of business rule specific development.
While solving one set of problems, BRMS development has exposed another. The business rules actually in use in an organization are embedded in diverse documents, in legacy computer systems, in regulatory filings, in individual employee's memory, and in practices that have been established by habit among employees. Even business rules automated in BRMS software are in a form not easily recognizable by non-programmers. Asked to discover the business rules in an organization, analysts and the business users with whom they work are faced with an effort for which little support exists, whether in theory, in methodology, or in software tools. Frequently the process of discovering business rules in practice exposes business rules actually in use in the organization that management may consider the incorrect business rules for the business to be using. At other times opportunities may be seen to improve the business rules in use once they are properly understood. This leads to opportunities to use a business rules approach to support a business re-engineering initiative.
BRMS software products assume that the analysts know the business rules. However, the effort to gather the business rules may be greater than actually programming the BRMS with those business rules. Separating the business rules from the rest of the requirements of a business system has exposed the reality that the industry has done a poor job of fully understanding and exposing business logic for the purpose of implementation into systems. Similarly, investigations into business rules actually in practice in automated systems as well as in manually operated systems have revealed that many of the business rules being employed in practice are not those that management understood to be employed, or that management (whether for business policy or regulatory purposes) required to be employed. These problems, exposed by this focus on business rules, are not new, but have become clear in the very recent past.
What is desired, therefore, is a method and system for discovering and managing business rules, clearly separated from other business and system aspects. Such a system should provide management with a clear understanding of the business rules that are employed or are to be employed in business systems.
From early in the evolution of software systems, the notion of abstracting complex systems into visually represented diagrams has played an important role in simplifying the tasks of design. The early visualizations were nothing more than black and white diagrams on paper, sometimes depicting program flow, sometimes data flow, and often the modular structure of the system.
Over time, the relationship between modeling and visualization became clearer. Theories such as the “Relational Model of Large Data Sets” in 1970 led to the development of models of data that vendors were able to use to represent large and complex data structures in simple two dimensional diagrams that became universally understood (“data models”) because of the ubiquity of the theory. As the sophistication of the software supporting the data models increased, it became possible to generate data models from the data structures, or create a database from the model. In more recent times models have become complex, computer stored and generated, with multiple views of representation and abstraction. So some aspects of an entire organization (for which there are modeling techniques) may be modeled and represented in an abstract, graphical representation.
The use of “visualization” to assist in dealing with the complexity of modern computer systems has given rise to the notion that whole systems can be designed, and then implemented into computer systems, by the creation of visual models. This concept is referred to as Model Driven Architecture (MDA), which is sponsored and supported by the OMG (Object Management Group), a major software industry standards consortium. Ultimately, the aim of MDA is that computer systems will be generated automatically from their model representations, without the need for programming.
The MDA, in the OMG approach, is delivered at three levels of abstraction: the Computation Independent Model (“CIM”), the Platform Independent Model (“PIM”), and the Platform Specific Model (“PSM”).
The CIM uses an appropriate domain-specific language (that is to say, a language applicable to the type of business being modeled, i.e., the insurance industry, or the travel industry, or the glass manufacturing industry, and so on). This model is designed to be independent of whether the system is to be automated (i.e., digitized or computerized), and independent of any particular form of computer system or platform. The value of the CIM is that it is meant to be understood equally well by business people as well as technologists, providing these groups with a shared understanding of the requirements, and is meant to represent the business system from a purely business perspective.
The CIM provides the input to the PIM when the system is targeted to be computerized. This is where the abstraction level is made more meaningful to the technologists so that they can use these models to understand the technical requirements of the system. The PIM is meant to be used by the technical architects of the computerized solution.
The PSM is where the model is made specific to the type of computer platform in which the system is to be implemented, e.g., CORBA, .NET, the Web, etc. The PSM may use different domain specific languages, or a general purpose language like Java, C++, PHP, Python, etc. Automated tools generally perform this translation.
The BRMS, in providing for business rules, is at a PSM level. Each vendor has their specific syntax and approach for the expression and/or modeling of business rules. To date, little or no modeling exists for business rules at the CIM or even PIM levels.
Consistent with the theory of “separation of concerns”, models in MDA are separated into architectural tiers. Of all the tiers, perhaps the greatest advance in the area of MDA is business process modeling. Using tools called “Business Process Management Suites” (BPMS), users are able to create a graphic depiction of a business process at increasing levels of detail, until the highest detail of process steps are achieved. These models are able to be established at the CIM level. Once the graphic representation at the CIM level is complete, the user is able to generate a resulting system at the PIM level, and, today, even at the PSM level. In some cases, the model so produced is theoretically capable of running a fully automated digitized system representing the CIM designed process. Examples of BPMS vendors and their products include: Pegasystems Inc. (SmartBPM Suite), Tibco Software (iProcess Suite), Appian Corporation (Appian Enterprise), and Metastorm Corporation (Metastorm BPM).
Notwithstanding the progress made in the area of graphic depiction of business processes, BPMS software tools suffer in general from the inability to separate business rules from the business processes that they model (i.e., creating a CIM, or even a PIM of the business rules), defeating the principal of “separation of concerns”, and also are unable to provide the business users or management with an understanding of the business rules used in the system. In addition, while processes are modeled in these tools, the business rules that they do provide for in the processes are not truly modeled, they are generally simply textual statements. Thus, business users are in the same position as previously noted above, with no means to create a model of the business rules for visualization purposes.
The significant difference between the nature of business processes and business rules should be understood to clarify why the two aspects should be separated in distinct model and physical forms, and how they should be connected one to the other. Process is a sequential activity, by definition connecting one business task to another by actions or messages. Process is ideally modeled as a series of task nodules (“tasks”) connected by sequence arrows. At a point in the process, a task may be invoked in which a business decision will need to be made. At that point a transition takes place between the sequential nature of the process and a declaratory nature of the logic that is executed to resolve the business decision, which is to say that one or more business rules are executed. These business rules need not be specified (or executed) sequentially, but in declaratory fashion. Once the business decision is made (i.e., all the business rules (or business logic) necessary to resolve that business decision has been executed), control is passed back to the process, and the next appropriate task is executed in the sequential flow. Thus, business rules need their own modeling paradigm and venue, and these need to be separate from the business process model. In current systems business rules merely are captured as text, or as requirements, or in a proprietary syntax.
What is desired, therefore, is a system and method in which business rules are captured in a visual CIM, separated from a process-modeled representation with clear connections to the process models.